home *** CD-ROM | disk | FTP | other *** search
/ Amiga Collections: Various / S.N.A.G. Disk of the Month 90-07 (1990)(Southern Nevada Amiga Group)(PD).zip / S.N.A.G. Disk of the Month 90-07 (1990)(Southern Nevada Amiga Group)(PD).adf / Funstuff / FireWorks! / WORKS.MOD < prev    next >
Text File  |  1990-06-24  |  3KB  |  62 lines
  1. Modifications to WORKS:
  2.  
  3. 1.21  The explosions were still too fast, so I once again slowed
  4.       them down.  Now they look like the did originally.  Went from
  5.       20 frames/sec to 15.  You figure out how much CPU tie you got
  6.       back.  I don't feel like it.
  7.  
  8.       Oh, by the way.  I lied in 1.20.  It's now 24 bytes smaller
  9.       than 1.20, and 32 smaller than the original.  I'm serious
  10.       this time... I can't make it any smaller.  Honest.
  11.  
  12. 1.20  Just realized that on a PAL screen the flares would start part-
  13.       way up the screen and that the fix (below) would always be
  14.       visible.  I add 56 raster lines (I believe a PAL screen is ? x
  15.       256 [512 interlace]) to my screen and move the flare origins
  16.       down 56 if GfxBase says the program is running on a PAL system.
  17.       I dunno if these work, since I haven't got a PAL system.  If
  18.       anyone with PAL ever gets this program, tell me if it works
  19.       (pun intended).
  20.  
  21.       Now takes up 20-25% of the CPU during the explosion, as opposed
  22.       to about 80-85% for the original, which is fairly good.  Simply
  23.       moving the mouse nomrally takes about 20-25%, for example.  It's
  24.       about 5-10% for the flare.  The unblanked mode is negligible.
  25.  
  26.       Fixed a bug that would crash works if there was an old CTRL-C
  27.       waiting around for someone to notice it when works exited.
  28.  
  29.       Executable 4 bytes smaller than 1.10, 8 smaller than original.
  30.       This will not happen again.  There is nothing left to trim.
  31.  
  32. 1.12  Explosions didn't look right (too fast, too many dots), so I
  33.       altered them.  Also, I fixed it so that even if sprites do
  34.       somehow get stretched, they should be all but invisible.  I did
  35.       this by putting sprites behind graphics and using holes in a
  36.       black foreground onto a cycling colored background as the dots
  37.       instead of putting cycling dots onto a black background.  This
  38.       new fix may, however, cause problems with monitors that can see
  39.       past overscan boundaries (I understand multisync's with flicker-
  40.       fixers do this).  I already had to increase the overscan because
  41.       it was possible to see it on a 1080.  I'm including a command
  42.       line option to force the program do it the old way.
  43.  
  44. 1.10  Fast SetPixel() routines added (courtesy of Jeff Petkau).  More
  45.       performance improvements.  Now takes about a third of the CPU
  46.       time it used to, so it shouldn't be a bother unless you're
  47.       running a ray-tracer while the screen is blanked.  Unblanked
  48.       CPU usage is negligible.  Executable size has been trimmed down
  49.       to four bytes less than that of the original.
  50.  
  51.       NOTE:  The system has a nasty habit of turning off sprite DMA for
  52.       me when the current scan line includes the pointer (or any other
  53.       sprite, for that matter) which results in the portion of that
  54.       sprite on that scan line being stretched out vertically.  I
  55.       changed a few things and it should be (it seems to be) a rare -
  56.       if not non-existent - occurrence.
  57.  
  58. 1.01  Some math sped up, more dots per explosion and faster explosions
  59.       as a result.  Not a hell of a lot else.
  60.  
  61. 1.00  First release.
  62.